COMPUTERIZED METHOD, APPARATUS AND SYSTEM FOR ISSUING 

SURETY BONDS 

This application claims priority on United States Provisional Patent 
Application Serial No.60/161, 212, filed October 22, 1999. 
Field of the Invention 

The present invention is in the field of improvements in the issuance of 
surety bonds and related products. 

Background of the Invention 

By the term surety bond is generally meant a bond issued by an insurance 
or other company as surety on behalf of a principal whereby the surety legally binds 
itself to an obligee for an amount of money guaranteed to the obligee for the faithful 
performance of a contract or other act of the principal. The bonds of the present 
invention can include bid bonds, contract, court and subdivision bonds, performance 
bonds, customs bonds, notary bonds, liquor license bonds, license and permit bonds, 
small business administration bonds, bail bonds, supersedeas bonds or other bonds 
required In litigation, etc. Also applicable to the invention are binding certificates of 
insurance and policy endorsements and other insurance related documentation. 

When a contractor, builder or supplier etc. wishes to bid on a construction 
project or submit a bid in connection with a governmental purchase of equipment or 
supplies the entity seeking bid typically requires that for a bidder to be considered for 
the job a bid bond must be submitted with the bid. Many municipalities have their own 
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bid form and others use a format approved of by the American Institute of Architects. In 
the typical bid bond the principal is the person who is submitting the bid. The surety is 
typically an insurance or bonding company who pursuant to the bond is "held and firmly 
bound" to the entity seeking the bid for a predetermined sum, usually some percentage 
of the bid amount. In the event the bid is accepted the bond becomes effective and 
protects the entity awarding the contract by assuring the entity of faithful performance of 
the contract as well as prompt payment of labor and materials furnished in performing 
the contract. In addition, the bond protects the bid seeking entity from the failure of the 
winning bidder from ultimately entering into the contract that is being awarded by paying 
the difference between the winning bid and the amount that the entity would have to 
pay to another party to complete the project because of the default. 

Each bidder submits a bid bond with its bid in the appropriate form 
decided upon by the entity seeking the bids. In the event the wrong form of bid bond is 
used the party submitting the bond runs the risk that the entity soliciting the bonds will 
reject the bid out of hand even if the person submitting the bond was the low bidder. 
Many agencies soliciting bids are reluctant to accept a bid with an improper bid bond 
form because there is a risk that the losing bidders who submitted the proper form may 
challenge the agency if it awards the bid to based on an improper bid form. 

When a contractor, for example, is submitting a bid, much of the 
contractor's effort is spent massaging the bid to make sure the contractor has a bid that 
he considers is his best for the particular job. Since much of the pre bid effort is spent 
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calculating and recalculating material and/or labor costs, frequently a bid bond is not 
sought by the contractor until just before the bidding deadline. In addition, many 
contractors are bidding on a plurality of jobs at a time. Furthermore, for many projects 
and contracts there are multiple bidders bidding on the project. For the non winning 
bidders their bond terminates and only the winning bidder's bond has any effect. As a 
result a great deal of effort has to be done in a short period of time to prepare multiple 
bonds. 

Surety companies typically rely on local agents to receive the bond 
request and process the necessary paper work to complete the bid bond. For certain 
bond requests where the amount of the bond request is low the agent may have 
authority to issue a bond without approval from the surety company. For other requests 
the surety company must approve the bond requests. One of the problems that agents 
have in submitting bonds for approval is that the requests are typically faxed to a central 
location at the surety company where they sit for an extended period of time before the 
request is presented to the proper person for approval of the request. Once the bond 
request is approved, the agent must prepare the actual bond which must be signed by 
the agent on behalf of the surety company. In order to save time in the process many 
surety companies provide their agents with executed powers of attorney for them to 
retain at their offices until needed. While this procedure saves considerable time in the 
procedure of issuing bonds there is also the risk that an agent could issue a bond 
inappropriately to an unsatisfactory party. While the procedure described above is for 
bid bonds, the current steps and procedures for issuing other types of bonds are 
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similar. 



As a result of the time deadlines and security issues in the current 
methods and procedures for issuing bonds there is a need for improved methods and 
apparatus for obtaining bonds. 



Objects of the Invention 



It is an object of the invention to provide a method of obtaining bonds 
using a computer system. 

It is an object of the invention to provide a system and apparatus for 
computerizing the issuance of bonds. 

It is an object of the present invention to provide increased security in the 
issuance of bonds. 

It is an object of the invention to improve the time necessary for issuing 

bonds. 



Summarv of the Invention 

The invention is directed to improved methods, apparatus and system for 
issuing and transmitting surety bonds, including but not limited to bid bonds, contract, 
court and subdivision bonds, performance bonds, customs bonds, notary bonds, liquor 
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license bonds, license and permit bonds, small business administration bonds, bail 
bonds, supersedeas bonds or other bonds required in litigation, etc. The present 
invention also has applicability in the field of insurance and other businesses including 
but not limited to binding certificates of insurance and policy endorsements. The 
invention relates generally to computerized systems and more particularly to a 
computerized system for automated issuances of bonds through a communications 
linkage for communicating and processing information necessary for the issuance of a 
bond in a timely and efficient manner. The invention also relates to a system for the 
collection, processing, and dissemination of bond related information generated from 
the application process. 

The present invention is a computerized system for automated execution 
of bonds through an Internet or Intranet website or other communications linkage for 
communicating and processing information. In addition, the present invention permits 
designated persons to view approved bonds from remote locations as a security 
feature. In order to log onto the system a user account and/or password are inputted. 

Brief Description of the Drawings 

Figurel A shows a block diagram of a representative computer system 
that would be used by the user to access information over a network such as an LAN, 
Wan, the Internet or an Intranet. 

Figure 1B is a block diagram of a system that allows access to a software 
application of the present invention over the World-Wide Web from a standard web 



browser; 

Figure 1C is a view of a representative logon page for access to the 

system. 

Figure 2 is a view of a representative agency nnain menu for the system. 

Figure 3 is a view of a representative agency pending bond search page 
for the system. 



Figure 4 is a view of a representative surety pending bonds page for the 

system. 

Figure 5 is a view of a representative pending bond page for the system. 
Figure 6 is a view of step 1 on a representative new bond page for the 

system. 

Figure 7 is a view of step 2, the contractor search, for the preparation of a 

new bond. 

Figure 8 is a view of step 3, the selection of the surety, for the preparation 
of a new bond. 

Figure 9 is a view of the page of Figure 8 with additional information 

added. 

Figure 10 is a view of a verification page for the new bond. 
Figure 1 1 is a view of an approved bond. 

Figure 12 is an enter contractor page which permits the agent to place his 
contractor information in the system prior to needing the information for a bond. 

Figure 12A is a contractor search page. 
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Figure 13 is a page listing approved employees of the agency. 

Figure 14 is a page for identifying the approved employees of the agency. 

Figure 15 is a representative page for an obligee to logon to view 
executed bid bonds. 

Figure 16 is a representative page for the obligee to submit the contractor 
code to view a contractors bond information. 

Figure 17 is a representative page showing the executed contractor's 

bond. 

Figure 18 is a flow chart showing the main client navigation. 
Figure 19 is a representative login dialog. 

Figure 20 is a flow chart showing the Managers section of the program. 

Figure 21 is a representative Manager's information form. 

Figure 22 shows a flow chart for the Sureties section of the program. 

Figure 23 shows a representative update form. 

Figure 24 shows a representative form used to add divisions. 

Figure 25 shows a representative form to add a surety 

Figure 26 depicts a representative form to add new employees of the 
surety to the system. 

Figure 27 shows a flow chart for the Sureties section of the program 
Figure 28 shows a representative form to update Agency information. 
Figure 29 shows a representative form to add subsidiaries. 
Figure 30 shows a representative form to add new employees of the 
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surety to the system. 

Figure 31 shows a representative preferred contractor form. 

Figure 32 show a representative flow chart for the contractors section of 

the program. 

Figure 33 shows a representative form used to Add a Contractor. 

Figure 33 shows a representative format used to add new employees of 
the contractor into the system. 

Figure 35 show a representative flow chart for the owners/obligee section 
of the program. 

Figure 36 shows an add employees form used to add new employees of 
the owners/obligees into the system. 

Figure 37 shows a representative flow chart for the bonds. 

Figure 38 shows a representative form used to update existing surety 

information. 

Figure 39 shows a representative form used to add surety divisions 
appears in Figure 39. 

Figure 40 shows a representative form that may be used to update 
agency information. 

Figure 41 shows a form to add agency subsidiaries. 

Figure 42 depicts a representative Database table layout. 
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Detailed Description of the Invention 



In the present invention the agent or other person seeking a bid bond or 
any other bond has a password and/or account number in order to logon to the system 
from a remote location using the Internet, an Intranet or other communication means. 
Figure 1A and Figure 1B show representative computer systems that may be used by 
the agent in connection with the present invention. The present invention is directed to 
a system and more preferably a computer network for accessing the information on a 
network, such as the Internet. The term computer network as used herein is used in its 
broadest sense, i.e., as any configuration of data processing devices and software 
connected for information exchange. The present invention can include personal 
computers, personal digital assistants (PDA's), set top boxes used on or in connection 
with televisions, and any other type of appliance that can access a collection of data 
such as the Internet. 

In one embodiment the appliance can include a network that serves to 
connect together a plurality of devices, e.g., terminals, computers, etc. Networks 
typically comprise a plurality of devices such as computers some of which function as 
servers to provide services to the other computers connected to the network. There are 
many types of computer networks in existence. They are known by various names 
including Local Area Network (LAN), Wide Area Network (WAN), Internet and the like 
and may be implemented in accordance with a variety of known architectures. 

Referring to FIG. 1 A, in one embodiment of the invention there is a typical 
transaction between a standard web browser or other communications software 212 
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running on a client workstation 210 and a web server or other software application 
permitting connnnunication with said workstation 222 running on a computer system 220 
occurs over a connection (communication link or communication mechanism) 216. 
Client workstation 210 may be coupled to other computer systems via a local area 
network (LAN) or via any other type of computer network or other interconnection. 
Likewise, computer system 220 may be coupled to other computer systems as well. 
Client workstation 210 may be any computer that is capable of providing access to a 
local area network (LAN) or via any other type of computer network or other 
interconnection to the WWW by using web browser or other communications software 
212. This would include handheld, portable or laptop computers, standard desktop 
computer systems, etc. 



Web browser 212 is a software program running on client workstation 210 
that allows a user at client workstation 210 to communicate with other computers over 
connection 216. Web browser 212 would include but is not limited to any web browser, 
which is capable of transmitting and receiving data over the WWW. This includes 
commercial software applications such as IBM's WebExplorer, Internet Netscape 
Navigator, Microsoft Explorer, Apple Computer's CyberDog, and any other software 
application which now exist or which may be developed in the future for accessing or 
processing information over the WWW. The preferred embodiment for connection 216 
is any suitable communication link or communication mechanism to the Internet, 
including by telephone, cable lines or other hard wired method, infrared or other 
wireless communications, wireless computer network communications, or any other 
suitable connection between computers, whether currently known or developed in the 
future. 
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It should be noted that client workstation 210 and web server computer 
system 220 may be the same physical and/or logical computer system. Web browser 
212 typically displays pages of data including but not limited to data in the form of 
HTML, XML, XHTML or their future incarnations to a user at client workstation 210. 
Other types of data (besides HTML) may also be transmitted to web browser 212, 
including text data, graphical data (e.g.. Graphic Image Format (GIF) files), audio data 
or sound files (e.g., WAV files), Java applets (executable code) and a specialized data 
form known as Multipurpose Internet Mail Extensions (MIME) data (which may include 
combinations of the foregoing and other data types). 

Web server application 222 is a software program running on web server 
computer system 220 that allows a user at client workstation 210 to access information 
controlled by web server 220. One preferred embodiment of web server application 222 
in accordance with the present invention is a commercial web server application such 
as IBM's Internet Connection Server. Other applications are also compatible with the 
present invention. Web server computer system 220 typically outputs pages of HTML 
data to WEB browser 212 in response to requests by web browser 212 that reflect 
action taken by the user at client workstation 210. In addition, as explained above, web 
server computer system 220 may output other types of data to web browser 212 as 
well. Output data may include static HTML pages (meaning that the content of the page 
does not vary), or may include data that must be dynamically determined and inserted 
into the output data. Web server application 222 may dynamically build output data 
(e.g., an HTML page) from parts that It retrieves from memory within web server 
computer system 220 or from other computer systems, or may simply pass through a 
page that has been constructed at an earlier time or by another computer. 

Web browser 212 typically interacts with web server application 222 by 
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transmitting input (e.g., a Uniform Resource Locator (URL) or an HTML page) over 
connection 216 to web server computer system 220. This input Is typically transmitted 
using HyperText Transfer Protocol (HTTP) 1 .0. Web server computer system 220 
running web server application 222 receives the input from web browser 212, and in 
response, outputs data (e.g., an HTML page) to browser 212. Web server computer 
system 220 may also have numerous other software components, including Common 
Gateway Interface (CGI) programs or modules, for performing desired functions. The 
process described above illustrates a basic transaction over the Internet, recognizing 
that many details and variations that are within the scope of the present invention are 
not disclosed herein for the purpose of providing a simple context for understanding the 
concepts of the present invention. 

In a preferred embodiment, the user seeking a bond accesses the web 
site of the bonding agency usually by inputting a URL for the appropriate web site. The 
web page is displayed on the monitor of client workstation 210. Web pages are 
generally written in Hypertext Markup Language (HTML). However, they can be written 
in XML, XHTML or their future incarnations. When web server application 222 running 
on web server computer system 220 receives a web page request, it will build a web 
page In HTML or retrieve a file containing a pre-built web page and send it off across 
connection 216 to the requesting web browser 212. Web browser 212 understands 
HTML and interprets it and outputs the web page to the monitor of client workstation 
210. This web page displayed on the user's screen may contain text, graphics, and links 
(which are URL addresses of other web pages.) These other web pages (I.e., those 
represented by links) may be on the same or on different web servers. The user can 
retrieve these other web pages by clicking on these links using a mouse or other 
pointing device. This entire system of web pages with links to other web pages on other 
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servers across the world collectively comprises the "World-Wide Web" (WWW). 

Referring now to FIG. 1 B, a computer system in accordance with one 
embodiment of the present invention may include: one or more Central Processing 
Units (CPUs) 110; a terminal interface 150; an auxiliary storage interface 160; a 
workstation 170; a Direct Access Storage Device (DASD) 180; a floppy disk 190; a bus 
140; and a memory 130 which includes multiple locations for containing various 
software programs. In this example, memory 130 includes a web browser 212 running 
in location 132, a web server application 222 running in location 134, an 
Internet/application gateway program 332 running in location 136, and a software 
application 342 running in location 138. 

CPUs 110 perform computation and control functions of system 100. All 
CPUs associated with system 100 may each individually comprise a single integrated 
circuit, such as a microprocessor, or may comprise any suitable number of integrated 
circuit devices and/or circuit boards working in cooperation to accomplish the functions 
of a central processing unit. All CPUs are capable of suitably executing the programs 
contained within memory 130 and acting in response to those programs or other 
activities that may occur in system 1 00. 

Memory 130 is any type of memory known to those skilled in the art. This 
would include Dynamic Random Access Memory (DRAM), Static RAM (SRAM), flash 
memory, cache memory, etc. While not explicitly shown in FIG. 3, memory 130 may be 
a single type of memory component or may be composed of many different types of 
memory components. For example, web browser 212 running in location 132 may be 
part of system 1 0O's cache memory. In addition, memory 1 30 and CPUs 1 1 0 may be 
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distributed across several different computer that collectively comprise system 100. For 
example, web browser 212 may reside on one computer with CPU, web server 
application 222 may reside on another computer system with a separate CPU. sub. 2, 
Internet/application gateway 332 may reside on a third computer system with a different 
CPU.sub.n-1, and software application 342 may reside on a fourth computer with a 
different CPU.sub.n. Computer system 100 of FIG. 3 simply illustrates many of the 
salient features, without limitation regarding the physical location of CPUs 110 or 
memory locations within memory 130. 

Bus 140 serves to transmit programs, data, status and other forms of 
information or signals between the various components of system 100. The preferred 
embodiment for bus 140 is any suitable physical or logical means of connecting 
computer systems and components known to those skilled in the art. This includes, but 
is not limited to, direct hard-wired connections, Internet connections. Intranet 
connections, fiber optics, infrared (IR) and other forms of wireless connections. It is 
anticipated that many alternative methods and material for connecting computer 
systems and components will be readily adapted for use with the present invention. 
This would include those methods and materials not presently known but developed in 
the future. 

Terminal interface 150 allows human users to communicate with system 
100, normally through programmable workstation 170. Although system 100 as 
depicted in FIG. 11 contains only a single workstation 170, it should be understood that 
the actual number of workstations attached to system 100 will be a function of system 
design and user preference. Workstation 170 may also be a dumb terminal or other 
non-programmable computer input/output device which allows human interaction with 
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computer system 100. 



Auxiliary storage interface 160 represents any method of interfacing a 
storage apparatus to a computer system known to those skilled in the art. Auxiliary 
storage interface 160 allows auxiliary storage devices such as DASD 180 to be 
attached to and communicate with the other components of system 100. While only one 
auxiliary storage interface 160 is shown, the present invention anticipates multiple 
interfaces and multiple auxiliary storage devices such as DASD 180. As shown in FIG. 
3, DASD 180 may be a floppy disk drive which is capable of reading and writing 
programs or data on floppy disk 190. DASD 180 may also be any other type of DASD 
known to those skilled in the art. This would include CD-ROM drives, hard disk drives, 
optical drives, etc. Floppy disk 190 represents a typical 3.5 inch magnetic media disk 
known to those skilled in the art. 

The agent using the present invention is pre-approved by a surety 
company just as the agent is currently pre-approved by one or more surety companies. 
Under the present invention the agent is not provided with a number of executed power 
of attorney forms by the surety company as is done with the present system. This 
avoids the risk of the agent granting unauthorized bonds. As seen in Figure 1C, the 
agent inputs the user name and the password to access the system. Once this data is 
typed, the user may be logged in. 

Figure 2 depicts the main menu which appears after login. The system 
has identified the user and the date. Once logged in properly the user can navigate any 
part of the system. Once the agent supplies his or her password and/or account 
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number the agent has access where the agent can obtain a new bond, search for an 
approved bond, including older bonds, check on the status of a pending bond or search 
for a dead bond. The system is designed so that the agent will only have access to 
information only on those bonds which he is authorized to view. In the event the agent 
seeks a new bond, each bond request is entered into the system by the agency. The 
information inputted for each new bond typically includes the name of the contractor, its 
address, the identity of the owner/ obligee for whom the bond is required, the bond form 
required, the owner/ obligee's address, the bid date, the estimated contract price, the 
amount of the bid security, the contract number or IFB number, and a description of the 
job. A representative screen for a new bond is shown in Figure 6. Once this information 
is inputted into the system the bond information the program provides a list of sureties 
surety where the agent has been authorized and the agent selects the surety from the 
list. The obligees typically include governmental agencies, private owners, construction 
managers, and/or general contractors Figure 8 and Figure 9. In the event there are 
more than one contractors with the same name a screen similar to Figure 7 may appear 
in order for the choice to be narrowed down to the appropriate selection. 

One advantage of the invention is that the surety can rescind the agent's 
authorization at any time from the website, thus preventing unauthorized bonds being 
issued. In the event a surety wants to cease doing business with one of its current 
agent, under the prior system the surety had to recall all of the outstanding powers of 
attorney and rely on the good faith of the agent to return all the existing executed 
powers of attorney that the surety had previously provided to the agent. Since an agent 
is usually dropped by a surety for malfeasance of misfeasance there was always a risk 
to the surety company as the agent could bind the company to unauthorized obligations 
with the existing executed powers of attorney. This problem is solved by the present 
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invention since the surety no longer needs to supply the agents with pre-signed powers 
of attorney and the surety can remove an agent from its list of approved agents virtually 
instantaneously by access the program and removing the agent's authority. In that 
event the surety dropping an agent will not be identified as one of the sureties on the 
list for the agent to select. After selecting the surety, the agent can submit the bond for 
approval or the information can be retained in the system as a pending bond and can 
be submitted at a later time. 

Once the agent selects the appropriate surety for the particular bid and 
the agent seeks approval, the agent is given an opportunity to check over the 
information included for errors. Figure 10 shows a representative screen for the user to 
review the key information before the bond is executed. The NAIC code identifies the 
surety. The date and time to the second can be archived at the time of execution on the 
screen of Figure 1 1 . If the information in Figure 10 is correct then the time of the 
application is recorded since many obligees require that a bond be obtained prior to a 
particular deadline and the bid information is transmitted directly to the appropriate 
person at the surety electronically. A cautionary notice should appear prior to approval 
of the bond. This warning will query the user to be sure that the bond is to be approved. 
When the bid information is transmitted to the appropriate person at the surety, that 
person's computer will provide a message that a bid has been received. This approach 
avoids the delays inherent in the prior system where facsimile transmissions of the bid 
information were relied on. Where a facsimile was used, the bid information would be 
transmitted to the fax machine which was not necessarily near the desk of the person 
with responsibility to act on the bid application. The agent would then have to wait until 
the bid was brought from the fax machine location to the surety's appropriate person. 
This added delays to the system that are avoided using the present invention. 
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Under the prior system of obtaining bonds once the bond was approved 
by the surety the agent would then have to put the paper work together and send it to 
the contractor. Since the bond was typically not requested by the contractor until just 
before the deadline delivery to the contractor usually required hand delivery or delivery 
by overnight courier with all the trouble that weather and other delays can engender. 
Under the present invention these problems are avoided. Once the bid is approved, the 
contractor is provided with a code number typically called an authorization code. Figure 
1 1 is a screen that shows the electronic bond. The contractor places the code on his 
bid papers and submits them to the obligee at the bid letting. The obligee logs onto the 
system and provides the contractors authorization code to review the bid. The surety 
can also use the system to search bonds by number as seen in Figure 16. The system 
also permits the surety to view, in real time all of the executed bonds of each agent for 
quality control purposes. Another advantage for the agent is that the agent can limit 
access to the system by limiting the individuals who access to the authorization code 
and/or password. Since the agent can change his password as necessary, the agent 
has more control over employees and can prevent certain employees from having 
access to the system. In addition, when an employee leaves employment the agent can 
change the password without having to worry about unauthorized access to bonds and 
bond information. Figure 12 is a contractor information screen for the contractor to input 
information. Figure 12A is a screen to search for a contractor. Figure 13 is a screen for 
the agency to input employee information for the employee to have authority to issue 
bonds. Initially, once the surety approves of the agent one key person at the agency will 
be the authorized person at the agency for all bonds. This may be the owner manager 
or some other person. This key person can, if desired, grant sub-authorizations to other 
employees that permit these additional persons to issue bonds. The number of these 
sub-authorizations may be increased, decreased or terminated completely as needed. 
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This authority can be readily cancelled if any impropriety is uncovered. Figure 14 shows 
a representative screen for the authorized employee of the agency to fill out to have 
access to the system. Figure 15 is a representative example of the log in page for the 
owner/obligee to access all the bonds information. For example, the name of the 
organization for whom the bonds were Issued may be inserted and information on all of 
the selected executed bonds is accessed. No changes or transactions may be made to 
the bonds. 

In Figure 3 an example of a screen for a user to search pending bonds is 
shown. The name of the contractor or the name of the owner/obligee is inserted and a 
search may be performed. In the event all pending bonds are to be searched, the fields 
are left blank and the user merely clicks the search box. Figure 4 shows an example of 
a listing of bonds in chronological order by the bid date. The list may be used as a dally 
or other work list of the bonds to be approved. The appropriate surety company can see 
the pending bond and accept it as a bid bond request. Figure 5 shows the screen for a 
pending bid bond. The screen lists all the necessary information in order for it to be 
approved. Figure 17 is an example of the electronic bid bond of the present invention. 
The exact date and time of the bid bond approval is archived. The name of the surety 
and the surety's NAC code is identified. This code designates the exact surety and 
avoids the confusion of similar surety names. The name of the person who executed 
the bid bond is at the bottom. This form can be modified so that the necessary 
information for each jurisdiction is available. 

Figures 18-42 show an alternate embodiment of the present invention. 
Figure 18 is a flow chart showing the main client navigation. 

[C-01] Initial Login to BMS V2.0 

The login requires the Manager, Surety, Agency, Principal or Contractor to enter their 
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Company ID, Username and password. The username and password are encrypted 
and stored within the database. The representative login dialog appears in Figure 19 

[C-02] Main Manager Section 

If the user has manager access, the user will have the choice of adding a manager or 
searching for viewing existing managers by name 

[C-03] Main Surety Section 

If the user has Surety access, the user will have the choice of adding a Surety or 
searching for viewing existing Sureties by name 

[C-04] Main Agency Section 

If the user has Agency access, the user will have the choice of adding an Agency or 
searching for viewing existing Agencies by name 

[C-05] Main Contractor Section 

If the user has Contractors access, the user will have the choice of adding a Contractor 
or searching for viewing existing Contractors by name 

[C-06] Main Bond Form Section 

Lists all of the Bond forms for the company that the user logged in belongs to. 

MANAGERS [CM-01 THRU CM-04] 

Figure 20 is a flow chart showing the Managers section of the program. 
[CM-01] Main Entry for Managers 

If the user has manager access, the user will have the choice of adding a manager or 
searching for viewing existing managers by name. 

[CM-02] Manager Search R suits 
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Allows Managers to search managers within their company by first letter or by name. 
The user can also delete the manager's information from this page. 

[CM-03] Add Manager Page 

Allows users with mangers access to add managers within their company. The 
representative Manager's information form appears in Figure 21. 

[CM-04] Manager Action Script to add, update or delete manager data 

Called by the add manager above to execute additions, updates or deletions. 

SURETIES [CS-01 THRU CS-18] 

Figure 22 shows a flow chart for the Sureties section of the program 
[CS-01] Surety Section Navigation 

If the user has surety access, the user will have the choice of adding a surety or 
searching for viewing existing surety by name 

[CS-02] Main Login Wnk 

The login requires the Manager, Surety, Agency, Principal or Contractor to enter their 
Company ID, Username and password. The username and password are encrypted 
and stored within the database. 

[CS-03] Bond Lookup 

This page contains scripts needed to look up existing sureties and branches tied to the 
company ID of the logged in user. 

[CS-04] List Surety Details 

Allows the listing of surety details. This includes surety divisions and branches listed 
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under the parent surety. 

[CS-05] Edit Surety Information 

Form used to update existing surety information. Representative update form 
appears in Figure 23. 

[CS-06] Add Surety Divisions 

Contains form to add surety divisions. Representative form used to add divisions 
appear in Figure 24. 

[CS-07] Surety Action Script to Add, Update, Delete surety or Add, Approve, 
Disapprove divisions 

This page is used to house scripts used to add, update, delete surety of add, approve, 
disapprove divisions 

[CS-08] List Surety Branches 

Form and logic used to display surety branches. The page also has an Add 
branches capability. 

[CS-09] Add New Surety 

Used to add a new surety. Representative form appears in Figure 25. 

[CS-10] Surety list of approved agencies 

The user can list and select approved agencies from this page. The user can 
also view the agency, the division that the agency is in and the approved limit for that 
agency. New agencies can be added and existing agencies can be edited or removed. 

[CS-11] Approved Surety Search Form to View Surety by name 

Search form to view approved surety by name. 
[CS-1 2] Surety Approv dS arch R suits 
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View search results for the view approved surety by name search. 

[CS-13] List Sur ty Employ s 

Displays list of employees and their access level within the system. The access 
types are listed as administrator, Executive or Clerical. 

[CS-14] Add Employees Form 

The add employees form is used to add new employees of the surety to the 
system. A representative form is shown in Figure 26 

[CS-15] Employees Add Action script to Add employee and company type 

This script adds employees for all entities within the system (Agency, Principle, 
Contractors and Managers. It also checks for duplicate users within the system. 

[CS-16] Preferred Contractors List by name 

Lists all preferred contractors for the logged in surety 

[CS-17] Company Bond Form 

Presents the appropriate bond form for the surety or agency 

[CS-18] Company Bond Forms action script to add bonds to the Company Bonds 
Forms database table 

Script used by the company bond form to add bonds to the system. 

AGENCIES [CA-01 THRU CA-18] 

Figure 27 shows a flow chart for the Sureties section of the program 
[CA-01] Navigation for Agency Section 

If the user has Agency access, the user will have the choice of adding an Agency or 



23 



searching for viewing existing Agencies by name 

[CA-02] Link back to Main Login 

The login requires the Manager, Surety, Agency, Principal or Contractor to enter 
their Company ID, Username and password. The username and password are 
encrypted and stored within the database. 

[CA-03] Bond Lookup 

This page contains scripts needed to look up existing sureties and branches tied to the 
company ID of the logged in user. 

[CA-04] Agency Details 

Lists details of the agency such as Company name, Subsidiaries, Employees, 
Employee permissions and branches. 

[CA-05] Update Agency Data 

Contains form to update Agency information. A representative form used appears in 
Figure 28: 

[CA-06] Agency Subsidiaries add and lookup 

Lists agency subsidiaries and provides a form to add subsidiaries. A representative 
add subsidiaries form appears in Figure 29: 

[CA-07] Contains Action Script to Update, Add agency, add subsidiary or Delete 

Uses input from the subsidiaries form above. Also is used to add or delete agencies 
and subsidiaries. 

[CA-08] List and Add Agency Branches 

This is used to list or add agency branches 
[CA-09] Add Agency or branch s 
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Form used to add an agency or branches. 
[CA-10] List of Agency Employ es 

Returns a list of agency employees 

[CA-11] Employee Add form 

The add employees form is used to add new employees of the surety to the 
system. A representative form appears in Figure 30. 

[CA-12] Employees Add Action script to Add employee and company type 

This script adds employees for all entities within the system (Agency, Principle, 
Contractors and Managers. It also checks for duplicate users within the system. 

[CA-13] Search Preferred Contractors 

Used to list preferred contractors by name 

[CA-14] Preferred Contractors Search Results 

Formats the above preferred contractor search results. Allows user to add 
preferred contractors as well. The form uses the federal tax id as the key for the 
search. The representative preferred contractor form appears in Figure 31: 

[CA-15] Preferred Contractor Action Script 

This page contains scripts used to update the contractor, add the contractor or delete 
the contractor. This script also builds the contractor ID. 

[CA-16] Preferred Contractors Add Results Form 

Returns a list of preferred contractors in the system. User may also add preferred 
contractors from this form 

[CA-17] Company Bond Form 

Presents the appropriate bond form for the surety or agency 

25 



[CA-18] Company Bond Forms action script to add bonds to the Company Bonds 
Forms database table 

Script used by the company bond form to add bonds to the system. 
CONTRACTORS AREA [CC-01 THRU CC-07] 

Figure 32 show a representative flow chart for the contractors section of 

the program. 

[CC-01] Contractor IMain Navigation 

If the user has Contractors access, the user will have the choice of adding a Contractor 
or searching for viewing existing Contractors by name 

[CC-02] Main System Login 

The login requires the Manager, Surety, Agency, Principal or Contractor to enter their 
Company ID, Username and password. The username and password are encrypted 
and stored within the database. 

[CC-03] Bonds lookup- Look up in Bid Bonds Table 

This page contains scripts needed to look up existing sureties and branches tied to the 
company ID of the logged In user. 

[CC-04] Contractor Details Lookup 

Lists details of the contractor information such as Company name and address. 
[CC-05] Contractor Employee Add, Update, Delete 

Representative form used to Add Contractor is shown in Figure 33. 
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[CC-06] Employee Add form 

The add employees form, a representative format which is shown in Figure 34,is used 
to add new employees in to the system. 

[CC-07] Employees Add Action script to Add employee and company type 

This script adds employees for all entities within the system (Agency, Principle, 
Contractors and Managers. It also checks for duplicate users within the system. 

OWNERS/OBLIGEE AREA [CO-01 THRU CO-07] 

Figure 35 show a representative flow chart for the owners/ obligee section 
of the program. 

[CO-01] Owner Main Navigation 

Main navigation for users logged in as owners. 
[CO-02] Main System Login 

The login requires the Manager, Surety, Agency, Principal or Contractor to enter their 
Company ID, Username and password. The username and password are encrypted 
and stored within the database. 

[CO-03] Get Owner Details and search by Bond number 

Lists details of the contractor information such as Company name and address. This 
form also allows the user to search by bond number 

[CO-04] Get Owner Bonds 

List bonds for the logged in owner. 
[CO-05] Owner Employe s List 
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Lists the employees for the owner obligee. 
[CO-06] Employe Add form 

The add employees form, a representative sample of which is shown in Figure 36, is 
used to add new employees in to the system. 

[CC-07] Employees Add Action script to Add employee and company type 

This script adds employees for all entities within the system (Agency, Principle, 
Contractors and Managers. It also checks for duplicate users within the system. 

BOND FORMS [CB-01 - CB-16] 

[CB-01] Bond Main Navigation 

A representative flow chart for the bonds for is shown in Figure 37. 
[CB-02] Main System Login 

The login requires the Manager, Surety, Agency, Principal or Contractor to enter their 
Company ID, Username and password. The username and password are encrypted 
and stored within the database 

[CB-03] Login Action Script to allow or disallow login 

This scripts decides system login authentication logic then, directs the user to the 
appropriate area. 

[CB-04] List Bonds for the agency or surety logged in 

Page Returns bonds for the agency or surety logged in 

[CB<05] List Details of Surety 

Allows the listing of surety details. This includes surety divisions and branches listed 
under the parent surety. 
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[CB-06] Edit Surety Information 

Form used to update existing surety information. A representative update form 
shown in Figure 38. 

[CB-07] Add Surety Divisions 

Contains form to add surety divisions. A representative form used to add divisions 
appears in Figure 39. 

[CB-08] Surety Action Script to Add, Update, Delete surety or Add, Approve, 
Disapprove divisions 

Tfiis page is used to liouse scripts used to add, update, delete surety of add, approve, 
disapprove divisions 

[CB-09] Create New Bond Step 1 

Search for a preferred contractor 
New Bond Step 1 : Search for a Preferred Contractor 
View Preferred Contractors By Name 
[CB-10] Create Bond Step 2 

New Bond Step 2: Select Preferred Contractor from returned list. 
[CB-11] Bond Step 3: Enter Bond Information 
[CB-11] List agency details 

Lists details of the agency such as Company name. Subsidiaries, Employees, 
Employee permissions and branches 

[CB-12] Update Agency Data 
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Contains form to update Agency information. A representative form that may be used 
appears in Figure 40: 

[CB-13] Agency Subsidiaries add and lookup 

Lists agency subsidiaries and provides a form to add subsidiaries. The representative 
add subsidiaries form appears in Figure 41 : 

[CB-14] Contains Action Script to Update, Add agency, add subsidiary or Delete 

Uses input from the subsidiaries form above. Also is used to add or delete agencies 
and subsidiaries 

[CB-15] Contractor Details from Contractors table 

Lists contractor information from related to this particular bond. 

[CB-16] Code to list and view the Bonds in the system 

This code will list and display completed bonds in the system. 

4.2 SERVER [S-01 THRU S-OX] 

[8-01] Server login- During the client login, the username and password are 
looked up in the database and granted or denied access depending on the user's 
account status 

[S-02] The Database server is preferably running Microsoft SQL Server 7.0. 
[S-03] A representative database table layout appears in Figure 42. 

SECURITY 

Preferably the databases are encrypted with 128 bit key encryption and the databases 
contain a specified list of users and specific roles the user has in the database. 
Preferably, the users each have a unique user name and password and the users are 
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able to view only the sections specified . 

In addition to the use of the present invention for bonds, those skilled in 
the art can also use the teachings of the invention for obtaining proof of insurance. 
Certificates of Insurance are also frequently required by contractors and others. 
Contractors are frequently required to present proof that their workers are covered by 
for example worker's compensation insurance. Certificates of Insurance are alsop 
required by many states before an automobile is registered. The present invention is 
useful in these applications also. One of the major advantages off the present invention 
is the reduction of fraud. In addition, there are significant cost reductions in the manner 
in which these insurance products are prepared pursuant to the teachings of the 
present invention. 
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